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ABSTRACT 

A  laboratory  testbed  facility  which  has  been  constructed  at  the  NASA  Lewis  Research  Center  for  the 
development  of  an  Intelligent  Control  System  (ICS)  for  reusable  rocket  engines  is  described.  The  framework  of 
the  ICS  consists  of  a  hierarchy  of  various  control  and  diagnostic  functions.  The  traditional  high  speed,  closed- 
loop  controller  resides  at  the  lowest  level  of  the  ICS  hierarchy.  Above  this  level  resides  the  diagnostic  functions 
which  identify  engine  faults.  The  ICS  top  level  consists  of  the  coordination  futKtion  which  manages  the 
interaction  between  an  expert  system  and  a  traditional  control  system.  The  purpose  of  the  testbed  is  to 
demonstrate  the  feasibility  of  the  ICS  concept  by  implementing  the  ICS  as  the  primary  controller  in  a  simulation 
of  the  Space  Shuttle  Main  Engine  (SSME).  The  functions  of  the  ICS  which  are  implemented  in  the  testbed  are: 
an  SSME  dynamic  simulation  with  selected  fault  mode  models,  a  reconfiguiable  controUei,  a  neural  network  for 
sensor  validation,  a  model-ba.sed  failure  detection  algorithm,  a  rule  based  failure  detection  algorithm,  a  diagnostic 
expert  system,  an  intelligent  coordinator,  and  a  user  interface  which  provides  a  graphical  representation  of  the 
events  occurring  within  the  testbed.  The  diverse  nature  of  the  ICS  has  led  to  the  development  of  a  distributed 
architecture  consisting  of  specialized  hardware  and  software  for  the  implementation  of  the  various  functions.  This 
testbed  is  made  up  of  five  different  computer  systems.  These  individual  computers  are  discussed  along  with  the 
schemes  used  to  implement  the  various  ICS  components.  The  communication  between  computers  and  the  timing 
and  synchronization  between  components  are  also  addressed. 
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INTRODUCTION 


An  Intelbgent  Contro^  System  (ICS)  is  under  development  at  the  NASA  Lewis  Research  Center  with  the 
primary  objective  of  improving  the  operability  and  maintainability  of  an  earth-to-orbit  propulsion  system.  In 
particular,  the  focus  of  this  technology  program  is  the  Space*Shuttle  Main  Engine  (SSME).  The  SSME  is  the 
first  large  scale,  liquid  propellant  reusable  rocket  engine  developed  from  a  long  line  of  expendable  rocket 
technology.  High  thrust  levels  required  for  a  typical  SSME  mission  have  pushed  the  notion  of  "reusability"  into 
the  future  by  requiring  post-flight  checkout  of  numerous  major  engine  components.  Merrill  and  Lorenzo  have 
proposed  a  framework  outlining  specific  functionalities  to  improve  the  durability  of  the  SSME  which  include 
active  control  of  key  engine  parameters,  real  time  diagnostics,  and  life  extending  control  [1]. 

An  aggressive  technology  program  has  been  in  progre.ss  at  LeRC  since  1989  with  proof-of-concept 
targeted  for  1 995  using  the  framework  proposed  by  Merrill  and  Lorenzo  as  a  road  map  for  technology 
development.  Towards  this  end,  a  simulation  testbed  has  been  assembled  providing  a  flexible  vehicle  for 
performing  the  research  necessary  for  development  of  ICS  functionalities.  In  addition,  the  simulation  facility 
provides  a  suitable  environment  for  examining  a  variety  of  fault  scenarios  and  demonstrating  the  capabilities  of 
the  ICS.  Effort  in  the  present  program  is  not  limited  to  the  synthesis  of  diagnostic  and  control  algorithms. 
Development  of  special  purpose  hardware  for  performing  various  ICS  functions  is  an  important  aspect  of  the 
present  program.  This  paper  describes  the  testbed  hardware,  the  testbed  software,  and  the  communication  and 
handshaking  between  individual  testbed  components.  It  will  also  address  future  plans  for  upgrading  the  present 
testbed.  Before  beginning  a  discu.ssion  of  the  implementation  of  the  ICS,  a  brief  overview  of  the  basic  capabil¬ 
ities  included  in  the  system  is  put  forth  in  the  context  of  the  furKtional  framework. 


INTELLIGENT  CONTROL  SYSTEM  FRAMEWORK 


The  ICS  functional  framework  in  Figure  1  contains  many  elements  of  the  original  framework  of  Merrill 
and  Lorenzo  but  is  slightly  narrower  in  scope  since  prognostic  and  life  extending  capabilities  are  not  considered 
for  the  near  term  demonstration.  The  primary  objective  of  the  program  is  the  successful  integration  of  on-line 
diagnostics  with  accommodation  actions  using  reconfigurable  controls  for  selected  fault  modes  of  rocket  engines 
[2). 


The  real-time  diagnostic  system  in  Figure  1  is  composed  of  sensor  validation,  model  based  failure 
detection,  rule  based  failure  detection,  and  ReREDS  (Reusable  Rocket  Engine  Diagnostic  System)  a  diagnostic 
sy.stem  developed  over  the  past  two  years  through  a  contract  with  System  Control  Technology  (SCT)  and 
Aerojet.  Each  subsystem  is  well  suited  to  identifying  a  certain  class  of  engine  faults.  In  this  way,  they 
compliment  one  another  through  their  respective  strengths  leaving  the  final  determination  of  an  engine  fault  to  a 
higher  level  diagnostic  expert  system.  The  diagnostic  expert  system  is  based  on  heuristic  rules  that  determine 
which  fault  has  actually  occurred  ba.sed  upon  the  data  provided  by  the  various  subsystems.  The  distributed  nature 
of  the  diagnostic  system  allows  a  divide  and  conquer  strategy  with  information  compression  performed  at  lower 
levels  in  the  hierarchy  to  relieve  the  computational  burden  in  the  diagnostic  expert  system  thereby  facilitating 
real-time  operation  [3).  The  engine  level  coordinator  makes  alterations  to  the  controller  using  engine  status 
information  generated  by  the  diagnostic  system,  and  propulsion  requirements  passed  down  by  the  propulsion 
level  coordinator  which  receives  thru.st  vector  commands  from  the  flight  controller.  Ultipiately,  the  engine  level 
coordinator  mu.st  satisfy  mitiimum  thrust  requirements  while  minimizing  further  component  degradation  and 
accommodating  failed  or  degraded  engine  hardware.  The  reconfigurable  controller  takes  requests  generated  by 
the  coordinator,  makes  the  changes  gradually  thereby  minimizing  engine  transients,  and  computes  the  valve 
positions  to  achieve  the  requested  behavior  from  the  engine.  The  control  is  robust  to  variations  in  engines  and 
degradations  in  components.  In  addition  the  control  takes  advantage  of  available  hardware  redundancy  in  the 
propulsion  system  to  maximize  fault  tolerance. 


THE  INTELUGENT  CONTROL  SYSTEM  TESTBED 


As  described  previously,  the  intelligent  control  system  framework  consists  of  various  control  and 
diagnostic  functionalities.  This  diversity  has  led  to  a  distributed  testbed  architecture  consisting  of  specialized 
computers  and  software  for  the  implementation  of  the  various  functions.  Having  specialized  computers  has 
simplified  the  development  process  and  has  provided  the  necessary  capabilities  required  by  the  different 
functionalities.  However,  a  distributed  implementation  does  pose  some  problems.  It  leads  to  increases  in 
communication  and  in  complexity.  Also  some  of  the  computers  do  not  have  the  capability  to  run  in  real-time  or 
have  limited  I/O  capabilities.  The  present  testbed  is  a  non  real-time  implementation  which  is  running  10  times 
slower  than  real-time.  The  main  purpose  for  the  present  testbed  is  to  demonstrate  the  feasibility  of  the  ICS 
concept.  In  the  future,  hardware  and  software  for  the  real-time  implementation  of  specialized  functions  such  as 
neural  networks  and  expert  systems  should  become  more  readily  available.  The  present  ICS  testbed  will  be 
upgraded  to  a  real-time  system  by  taking  advantage  of  such  advances. 

Figure  2  shows  the  Intelligent  Control  System  testbed  as  well  as  the  functionality  implemented  on  each 
to  the  five  computers.  It  should  be  noted  that  ReREDS  is  not  incorporated  into  the  present  version  of  the  testbed. 
However,  the  testbed  will  eventually  allow  the  entire  ICS  functional  framework  shown  in  Figure  1  to  be 
implemented.  The  five  computers  included  in  the  present  testbed  are  the  simulation  computer,  controls  computer, 
neural  network  computer,  diagnostic  computer,  and  a  computer  used  to  implement  the  graphical  user  interface.  It 
should  be  noted  th.at  ReREDS  has  not  yet  been  incorporated  into  the  testbed.  In  the  following  sections  the 
individual  computers  will  be  discussed  in  detail  along  with  the  communication  and  synchronization  between 
them. 


TESTBED  COMPONENTS 


Simulation  Computer 

A  non-linear  simulation  of  the  SSME  including  fault  mode  models  is  implemented  on  the  simulation 
computer.  The  simulation  computer  is  specifically  designed  for  the  real  time  implementation  of  continuous, 
dynamic  sy.stems.  The  system  consists  of  an  Applied  Dynamics  Sy.stem  100  simulation  computer,  analog  and 
digital  I/O  hardware  for  running  hardware-in-the-Ioop  simulatioRS,  and  a  Vax.station  II  front  end.  The  simulation 
computer  is  a  64-bit  floating  point  multiprocessor  which  is  optimized  for  numerical  integration.  The  I/O  facilities 
provide  analog  communications  to  allow  the  SSME  simulation  to  communicate  with  the  rest  of  the  ICS  testbed. 
The  Vaxstation  n  front  end  computer  is  where  all  of  the  program  development  occurs  such  as  editing,  compiling, 
and  linking  the  simulation.  The  Vaxstation  also  runs  data  collection  and  graphical  display  utilities  to  allow  the 
u.ser  to  monitor  and  evaluate  the  simulation  performance.  The  models  implemented  on  the  .simulation  computer 
are  coded  in  ADSIM.  a  proprietary  programming  language  of  Applied  Dynamics.  The  .simulation  is  updated  via 
an  internal  timer  at  a  u.ser  specified  update  rate. 


Controls  Computer 


The  SSME  multivariable  reconfigurable  controller,  the  intelligent  coordinator,  and  the  model  based 
failure  detection  algorithm  are  coded  in  FORTRAN  and  are  implemented  on  the  controls  computer.  The  controls 
computer  .system  is  known  as  the  Control,  Interface,  and  Monitoring  (CIM)  Unit.  This  unit  was  fabricated  in- 
house  at  NA,SA  Lewis  for  the  implementation  and  evaluation  of  advanced  digital  control  algorithms  with 
hardware  in  the  loop  (4|.  It  is  intended  for  use  in  both  simulation  facilities  and  engine  test  facilities,  and  is  there¬ 
fore  implemented  in  a  portable  equipment  rack.  The  controls  computer  consists  of  a  microcomputer  running  a 
real  time  operating  system,  interface  hardware  for  connecting  to  an  engine  simulation  or  actual  engine  hardware, 
and  monitoring  hardware  and  software  to  verify  that  the  control  is  performing  properly.  The  real  time  capabilities 
of  the  controls  computer  make  it  well  suited  for  running  the  reconfigurable  controller  as  well  as  the  intelligent 
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coordinator  and  the  model  based  failure  detection  algorithm. 

The  microcomputer  consists  of  a  33  MHz  80486  single  board  computer,  analog  and  discrete  I/O  boards, 
an  ethemet  controller  board,  and  disk  drives  with  their  associated  controller  boards.  The  circuit  boards  are 
mounted  in  an  industry  standard  Multibus  1  chassis.  The  microcomputer  runs  the  iRMX  real  time  operating 
system.  This  operating  system  provides  the  services  needed  to  construct  a  real  time  executive  to  schedule  the 
execution  of  the  multivariable  control  algorithm,  the  model-based  failure  detection  algorithm,  I/O  routines,  and 
the  data  collection  software.  The  executive  is  coded  in  PL/M  and  updated  by  a  timer  generated  interrupt  at  a  user 
specified  rate.  Analog  I/O  is  used  for  the  communication  from  the  controls  computer  to  the  simulation  computer 
and  the  neural  network  PC  A  bi-directional  digital  interface  is  used  to  implement  the  communication  between 
the  controls  computer  ;uid  the  diagno.stic  computer.  The  executive  schedules  communication  to  the  user  interface 
over  an  ethemet  link  ;uid  the  internal  data  collection  utility  as  lower  level  tasks. 

The  purpose  of  the  interface  hardware  is  to  route  signals  throughout  the  controls  computer,  to  connect 
the  controls  computer  to  external  devices,  and  to  buffer  tho.se  signals  if  desired.  Cables  carrying  analog  signals 
which  inter!. ice  to  both  the  AD  100  ;uid  the  neurid  net  PC  are  terminated  at  the  controls  computer  base  connec¬ 
tors.  A  patch  panel  is  available  to  control  the  routing  of  analog  .signals  throughout  the  system  and  to  allow  quick 
changes  in  the  configuration.  The  controls  computer  can  support  up  to  32  analog  outputs  and  64  analog  inputs. 
The  front  panel  of  tlie  controls  computer  has  32  lights  and  24  switches  that  can  be  configured  by  the  user  to 
perform  various  functions.  The  lights  arc  used  to  indicate  the  status  of  the  softwiu^e  executing  on  the  processor 
and  the  switches  are  used  by  the  operator  to  change  modes  of  operation. 

The  monitoring  capabilities  of  the  controls  computer  allow  the  user  to  ob.serve  analog  signals  that  are 
.sent  to  and  Irom  tlie  system,  as  well  as  record  variables  within  the  control  algorithms  during  execution.  A  data 
acquisition  system  monitors  the  control  computer  I/O  and  allows  the  operator  to  display  any  desired  signal  or 
signals  in  actual  voltages  or  engineering  units.  The  Microcomputer  Interactive  Data  System  (MINDS)  program 
runs  in  the  background  on  the  microcomputer  CPU  [.3J.  The  MINDS  program  has  both  steady-state  and  traasient 
data  collection  capabilities  ;tnd  can  acce.ss  any  variable  in  the  control  algorithm.  MINDS  allows  collected  data  to 
be  stored  to  hard  disk  or  displayed  to  the  termin.al. 


PC  Neural  Network  Implement.ation  System 

The  sensor  validation  neural  network  is  incorporated  into  the  ICS  testbed  through  the  PC  neural  network 
implement.ation  system  shown  in  Figure  3.  Tlie  hardware  consi.sts  of  .an  80286  PC/AT  c.abled  to  a  .separate 
exparcsion  chassis  which  essentially  extends  the  PC  bus  ami  provides  addition.al  expansion  slots.  This  chassis 
connection  was  necessary,  because  of  the  large  number  of  peripheral  boards  required.  Installed  onto  this  setup  is 
an  AN21A  Plus  neural  proce.ssor  bo.ard  from  Hecht-Nielson  Corporation.  This  board  does  not  actually  contain  true 
neural  network  devices;  such  neuriil  net  hardw.are  is  ju.st  now  beginning  to  appear  on  the  market  and  does  not  yet 
pos.se.ss  the  necessary  sophistication.  Rather,  the  ANZA  Plus  is  an  accelerator  board  which  utilizes  'be  Intel  i860 
reduced  instruction  set  computing  (Rl.SC)  processor  chip.  This  proce,ssor  has  the  ability  to  multir'v  and 
accumulate  in  a  single  cycle,  thus  allowing  it  to  .speed  up  interconnect  calculations  and  other  neural  computa¬ 
tions.  Sy.stem  communication  w.as  provided  by  in.stalling  analog  I/O  hardware.  This  hardware  provides  the  system 
with  an  I/O  capability  consisting  of  16  inputs  and  12  .analog  outputs.  Since  the  system  interface  consi.sts  of 
an.alog  signals,  the  neural  network  implementation  has  the  .appearance  of  a  true  analog  neural  net  to  the  other 
components  of  the  testbed. 

Ihe  software  developed  for  the  PC'  neural  network  implementation  sy<^iem  consists  of  a  main  executive 
program,  which  schedules  Ihe  operation  of  the  AN2L‘\  neural  processor  ami  the  I/D  boards,  as  well  as  various 
procedures  grouped  into  tunclional  modules  Tliis  mam  executive  perfome  the  required  declarations  and 
definitions  and  iniiiali/es  the  hardwarc  It  then  schedules  the  conversion  uf  analog  signals  into  neural  net  inputs, 
Ihe  download  of  input  data  to  the  ANZA  board,  the  iterafion  of  network  compul.ilions  on  the  ANZA  board,  the 
conversion  of  computed  neural  network  outputs  into  analog  signals  and  the  upd.aling  of  the  display  screen.  These 
operations  are  perfomied  by  the  executive  through  procedure  c.^’Ils.  Tliese  procedures  are  grouped  by  function 
into  the  following  modules:  I/O  procedures,  neural  net  procedures,  display  procedures  and  timing  procedures. 
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The  I/O  routines  provide  an  interlace  to  the  A/D  and  D/A  boards.  Tliey  initialize  conversions,  access  control  and 
data  registers  on  the  boaitls  and  peribnn  the  appropriate  scaling  of  input  and  output  data.  The  display  routines 
initializ.e  the  screen  and  jwvide  continual  display  updates  of  the  network  inputs  and  outputs  in  the  form  of  a 
graph.  The  timing  routines  provide  a  means  of  measuiing  the  cycle  update  times  for  benchmarking  purposes, 
even  though  the  system  is  configured  to  execute  as  fast  as  po,s.sible  and  is  not  synchronized  to  any  other  compo¬ 
nents  of  the  testbed.  The  neural  network  jtrocedures  arc  used  to  initialize  the  ANZA  board,  initialize  a  network 
structure,  load  pre-trained  weights,  pul  input  data  into  the  board,  initiate  net  iterations  and  get  computed  outputs 
from  the  board.  These  procedure,-)  interface  with  the  ANZA  processor  board  via  the  HNC  User  Interface  Subrou¬ 
tine  Library  (UlSL)  which  is  a  set  of  commands  used  to  control  processor  operations.  The  ANZA  board  was  not 
designed  to  implement  on-line  neural  network  oper.ating  within  an  environment  <  f  continuously  changing  inputs. 
The  present  neural  network  implementation  requires  approximately  .“iO  milli.seconds  for  each  update.  Much  of  this 
delay  can  be  attributed  to  the  lime  required  to  download  new  data  and  then  read  the  corresponding  outputs  from 
the  ANZA  board.  This  update  rale  is  sufficient  for  the  present  scaled  time  implementation  of  the  ICS  but  im¬ 
proved  hardware  will  be  needed  in  the  future  to  allow  us  to  implement  neural  networks  in  real  lime. 


Diagno.stic  Computer 

A  commercially  available  expert  system  .shell.  G2™  from  Gensym,  was  chosen  to  run  the  diagnostic 
expert  system  ami  the  component  failure  detection  algorithm.  G2  has  been  implemented  on  a  Vaxstation  3500 
computer  to  incorporate  it  into  the  IC.S  testbed.  Tite  user  defines  objects  I<)  represent  various  aspects  of  the 
environment  using  an  object  oriented  approach.  After  reviewing  currently  available  software  shells  in  the 
artificial  intelligence  field,  the  G2  expert  system  was  selected  based  on  three  main  criteria:  (1)  its  flexibility  in 
expanding  the  knowledge  ba.se:  (2)  its  capability  to  perfomi  numerical  simulation;  and  (3)  its  capability  to 
perform  on-line  inpul/output  operations  [6]. 

The  G2  software  package  provides  a  rule-ba.sed  inference  engine  which  allows  for  the  future  expansion 
of  the  knowledge  ba.se.  This  is  important  for  the  ICS  program  since  it  is  a  research  project  where  the  future 
addition  of  rules  is  a  certainly.  Another  important  feature  of  G2  is  its  integrated  simulation  capability.  A 
numerical  model  can  be  programmed  in  the  simulator  to  provide  a  possible  source  of  values  for  variables.  This 
simulation  facility  provides  the  potential  of  testing  the  knowledge  base  under  development  without  connecting  to 
an  actual  system.  Along  with  the  expert  system  shell,  an  interface  called  GSl'^’  can  be  set  up  to  provide 
input/output  data.  GSI  allows  the  inference  engine  to  operate  on  continuously  changing  input. 

One  major  limii.aiion  of  G2  is  its  s.ampling  ntle.  The  current  defined  minimum  sample  interval  is  one 
.second.  This  is  not  fast  enough  for  rocket  engine  fault  detection  and  is  one  of  the  key  reasons  why  the  present 
ICS  demonstration  is  not  mnning  in  real  time.  We  expect  th.ai  G2  will  let  us  gain  insight  into  how  the  real-time 
decision  making  process  should  be  handled  In  the  future  as  we  move  towards  a  real-time  te.stbed  implementation 
we  will  need  improved  software  l('  allow  us  to  implement  the  diagnostic  expert  system  in  real-time. 


Graphical  User  Interface  and  ReREDS  Computer 

The  Graphical  I 'scr  Interface  (CiUl)  and  ReRFD.S  arc  both  implemetited  on  a  TI  Explorer  II  Lx  +.  The 
GUI  was  developed  to  allow-  the  ICS  to  be  monitored  during  operation.  The  Gl.ll  pemiits  users  to  observe  the 
ICS  in  real-time  operation  -.ts  it  accommodates  faults  in  coni|ronent.s.  sensors,  and  actuators,  using  a  collection  of 
screens  designed  to  provide  a  clear  illustration  through  plots,  text,  and  anim.ation  of  the  entire  proce.ss.  The  TI 
Explorer  11  Lx  +  is  well  suited  for  the  development  of  knowledge  based  systems  and  is  well  suited  for  the 
ReREDS  application  which  is  coded  in  I  I.SP  However  its  object  oriented  piogramming  capacity  makes  the 
development  of  graphical  user  interfaces  straight  forward.  Ilie  GUI  is  a  full-color,  object-oriented  sy.stem  consist¬ 
ing  of  a  .set  of  screens  arranged  hieran  hic.ally.  Each  screen  consists  of  three  vvindows:  a  moiisc-.sensitive 
graphical  di.splay  window  containing  a  di.igram  of  a  component  or  system,  a  plotting  window  depicting  time 
responses  of  key  v.ariables  .associated  with  that  component  or  .sy.stem,  and  an  intcr.active  type-out  window 
displaying  messages  and  allowing  the  user  to  enter  commands.  Figure  4  shows  <in  example  screen.  The  top 


window  contains  a  view  of  the  space  shuttle  main  engine  composed  of  selectable  objects,  the  window  on  the 
lower  left  displays  messages.  ;uk1  that  on  the  lower  right  displays  plots.  The  CIM  Unit  pa.s.ses  data  and  coded 
messages  to  the  E.\plon.'r  over  an  Ethernet  connection.  The  Gtfl  plots  time  re.sponses  of  important  variables 
and  indicates  engine  faults  to  the  user  through  messages  in  the  type-out  window  and  by  causing  failed  mouse- 
selectable  components  to  flash.  The  user  may  bring  up  more  detailed  screens  by  clicking  the  mouse  on  the 
objects.  Because  of  the  niixluhu.  object-oriented  nature  of  the  GUI.  the  creation  of  additional  screens  is  simple 
and  quick.  Thus  appropriate  screens  ciui  be  added  easily  as  more  fault  modes  are  incorporated  into  the  testbed 
system. 

SYSTEM  COM^WN^CATIONS  AND  SYNCHRONIZATION 

The  implementation  of  a  system  distributed  ;unong  several  different  computers  naturally  yields  a  rather 
complex  communication  system.  The  Intelligent  Control  System  implementation  consists  of  tuialog.  digital,  and 
network  communications  as  shown  in  Figum  2.  From  the  diagram  we  can  see  that  the  controls  computer  is  the 
hub  of  testbed  communications.  The  reason  for  this  is  twofold.  The  controls  computer  is  running  the  multivari¬ 
able  controller.  tlK'  engine  level  coordinator,  and  the  model  based  failure  detection  algorithm  which  are  central 
components  of  the  ICS  fnu.iework.  The  controls  computer  also  supports  a  wider  array  of  communication  options 
than  most  of  the  computers  in  die  testbed.  Tlx^reforc  two  computers  that  needed  to  share  data  but  did  not  have  a 
compatible  communication  link  resolved  the  problem  by  tnuisferring  data  through  the  controls  computer.  For 
example  sensor  validatioti  mfomiation  calculated  in  the  PC  neural  rKM  implement.ation  system  is  passed  enroute  to 
the  diagnostic  expert  system  on  the  iliagnoslic  computer  through  the  controls  contpuier. 

All  I/O  between  the  engine  simulation,  controls  computer.  ;md  scn.sor  validation  neural  netwoik  is 
analog.  This  implementation  is  straight  forward  and  is  rcpre.sentative  of  an  actual  engine  w  here  the  sensor 
outputs  and  actuator  inputs  would  be  in  the  form  of  analog  .signals.  Each  of  the  three  computers  use  12  bit  A/D 
and  D/A  converters.  Incoming  analog  values  are  scaled  to  their  corresponding  values  in  engineering  units. 
Similarly,  outgoing  signals  lue  scaled  before  being  .sent  to  the  D/A  converters.  The  neural  net  PC  is  running 
asynchronou.sly  front  the  other  computers  within  tite  testbed.  It  presently  requires  50  miUi.scconds  to  update,  most 
of  wliich  can  be  attributed  to  the  requia-d  transfer  of  data  in  and  out  of  the  neural  network  accelerator  board  on 
each  update.  The  controls  ctmiptiter  uses  a  multitasking  scheme  to  .schedule  the  execution  of  its  software, 
communication.  ;utd  data  collection  responsibilities.  The  multivariable  controller  and  the  nuxlel  based  failure 
detector  arc  designed  ti'  uptlate  in  real  tiitte  at  rates  of  10  milliseconds  and  40  milliseconds  respectively.  The 
scaled  versions  run  at  100  and  400  nttlliseconds.  TItere  are  five  different  tasks  scheduled  to  operate  on  the 
controls  computer  These  tasks  have  been  intplentented  so  that  the  fastest  ;uid  most  urgent  tasks  have  the  highe.st 
priority.  This  means  that  tliey  can  temporarily  suspend  all  lower  priority  tasks  until  they  have  completed 
operation.  The  five  tasks  are  as  follows:  The  highest  priority  task  executes  the  multiv.ariable  control,  the  engine 
level  coordinator,  .and  handles  the  analog  I/O  as  well  as  communication  over  the  DRl  1  interface.  The  second 
task  executes  the  model  bascti  failure  detection  algorithm.  Tlie  third  task  performs  MINDS  transient  data 
sampling.  The  fourth  task  pcrlomis  the  transfer  of  data  to  the  user  interface  over  the  ethemet  connection  The 
fifth  arnl  lowest  pri(>nty  task  is  the  MIND.S  utility  which  interprets  u.ser  input  supplied  from  the  keyboard.  Figure 
3  .shows  a  diagram  for  the  live  tasks  lu'ranged  from  top  to  bottom  in  tlic  onler  of  their  priority.  This  figure  is 
intended  for  illustration  purposes  arxl  does  not  accurately  represent  the  relative  execution  times  for  the  five  tasks. 

The  interlace  between  the  cc’ntrols  computer  ;ukI  the  diagnostic  computer  is  implemented  through  a 
DRl  I  interface  Tliis  is  a  bi-directional  parallel  digital  intcrf.ice  which  transfers  data  in  16  bit  words.  Figure  6 
shows  the  interaction  between  the  controls  computer  ;uid  tlx*  G2  application  running  on  the  diagnostic  computer. 
The  diagnostic  computer  sets  a  Hag  wlien  it  wishes  to  send  or  receive  data  and  then  waits  for  tlie  controls 
computer  li’  respimd  The  controls  computer  polls  the  same  tlag  on  each  update  Wlien  it  detects  that  the  flag  has 
been  set.  it  initiates  the  data  transfer.  Tins  pi'lling  sdK’nie  insures  that  the  controls  ci'iiiputer.  which  is  operating 
at  a  much  faster  upriate  rate,  is  never  idle  and  waiting  for.  the  diagnostic  computer  to  respond. 

Inform.ation  is  transferred  from  die  controls  computer  to  the  user  interface  over  an  ethemet  connection. 
The  TCP/IP  pnrtocol  is  used  to  develop  the  software  to  transfer  packets  of  floating  point  data.  As  shown  in 


Figure  5,  the  task  on  the  controls  computer  which  handles  this  communication  is  assigned  a  relatively  low 
priority.  This  is  because  of  the  delay  and  non-deterministic  behavior  associated  with  data  transmission  over 
ethemet. 


SUMMARY 


A  testbed  which  has  been  developed  at  the  NASA  Lewis  Research  Center  for  the  implementation  of  an 
Intelligent  Control  System  (ICS)  for  earth-to-orbit  propulsion  systems  is  described.  The  diverse  nature  of  the  ICS 
has  led  to  the  development  of  a  distributed  testbed  consisting  of  specialized  hardware  and  software.  The  present 
testbed  is  being  used  to  demonstrate  the  operation  of  the  ICS  in  scaled  time.  Future  plans  include  upgrading  the 
hardware  and  software  to  obtain  real  time  operation  and  also  expanding  the  testbed  to  include  additional 
functionality. 
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Figure  1.  Intelligent  Control  System  Functional  Framework 
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Figure  2.  Intelligent  Control  System  Simulation  Testbed 
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Figure  4.  Graphical  User  Interface  Screen 
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